Programs for data processing devices are increasingly used for processing and presenting, as examples, image data files or video data files on a display. Similarly, programs are used for handling audio data files, for example, for recording and playback of voice data files, music data files and the like. Image, video, and audio data files typically comprise binary data blocks. For example, an image file is usually stored as an array of pixels in which each pixel is described by multiple information values (e.g., bytes of color data). Thus, in many instances, image or video files contain large amounts of data to be managed. Audio data files may also grow very large, particularly when voice or music information is sampled at high data rates and each sample is represented by digital information.
When handling binary files or data blocks with data processing devices, a memory area is usually allocated for storing the binary data block representing the image, video, or audio data.
For example, when generating a web-page for display at a browser, memory space will be allocated for images and text elements, as examples. In situations where one graphic element (e.g., an icon indicating a selection of options) is to be displayed multiple times, memory space may be allocated for each representation of the graphic element. When large data blocks underlie the graphic elements, a substantial amount of memory space may be used, resulting in poor performance and lack of available resources for other programs.
In the past, identical graphic elements were represented by a specific handle that allowed sharing internal data structures several times. As a result, a graphic element displayed multiple times occupied one memory space and the program accessed that memory space several times to generate, for example, a bitmap to be output on a display.
The past approach, however, did not perform well in cases where (as one example) graphic elements were inserted by a program sequentially. The poor performance was due in part to the fact that the program did not necessarily know about the existence of a memory area already storing the desired graphic element. This problem was compounded when more than one program accessed the same image, audio, or video data block, because the programs did not know of the internal data structures generated by other programs, particularly in a server-client environment where programs are executed on a server are remotely controlled by a client. For example, numerous clients could access a particular server and independently start a number of programs and instruct these programs to display the same graphic element. The programs would then allocate a memory area for the graphic element for each of the clients communicating with the server, possibly exceeding available memory at the server. Even if it is known that identical descriptors (e.g., URLs) of binary data blocks are in use, a memory area for the data blocks may not be shared.
Furthermore, in scenarios where a client remotely controls a program on a server, and a binary data block (e.g., a graphical element) needs to be transferred to the client multiple times (e.g., for building display content at the client), large bandwidth requirements will arise due to the retransmission of the graphical element multiple times. When the client is connected to a server executing the program on behalf of the client through a low bandwidth communication link, such as a wireless communication link or a telephone line, unacceptably high latency results.
A need has long existed for techniques that address the problems noted above and others previously experienced.